Improving Quality of Software through Formal Inspection

The software inspection process was created for the dual purpose of improving software quality and increasing programmer’s productivity. Formal inspection is a better method than technical walkthroughs in the software life cycle process. benefits gained in the development of defect-free software by utilizing formal inspection Formal inspections may be applied to any product or partial product of the software development process, including requirements, design, and code. The software formal inspections are in-process technical reviews of a product of the software life cycle, which aims to detect and eliminate defects in the early stages of each products development. In addition, the evaluation from the formal inspections can be immediately fed back to the author with improvements in the quality of future products. KeywordsAppraisals, Fagan Inspection, Formal inspection, Milestones, Quality assurance, Walkthroughs. INTRODUCTION The software inspections were first introduced by Michael E. Fagan in 1970s, when he was a software development manager at IBM. The inspection process for software development was also developed as it was practiced by IBM at that time. To distinguish the software inspection from general inspection, the software inspection should be called the in-process inspection. For simplicity, we frequently use the term "inspection" as synonymous with "in-process inspection". Software inspections allow software development teams to find defects earlier and cheaper, thus reducing rework costs. In addition, there are other benefits more difficult to quantify. Software inspections aid in project management; and they provide more definite and more dependable milestones than less formal review processes. Software inspections can also promote closer teamwork, provide on-the-job training, and support the transfer of skills from more experienced team members to others. There are some costs to starting up inspections, specifically in training management, moderators, and inspectors. The conduct of trained moderators and the attitude of management are key to the acceptance of inspections by engineers. Inspection results should not be used for personnel performance appraisals. An inspection is one of the most common sorts of review practices found in software projects. The goal of the inspection is for all of the inspectors to reach consensus on a work product and approve it for use in the project. Commonly inspected work products include software requirements specifications and test plans. In an inspection, a work product is selected for review and a team is gathered for an inspection meeting to review the work product. A moderator is chosen to moderate the meeting. Each inspector prepares for the meeting by reading the work product and noting each defect. The goal of the inspection is to identify defects. In an inspection, a defect is any part of the work product that will keep an inspector from approving it. For example, if the team is inspecting a software requirements specification, each defect will be text in the document which an inspector disagrees with. There are various names for the same thing. Some call it software inspection, which also could extend to the design and its documentation; some call it code inspection which relates more to the source code. A third name would be Fagan Inspection, called after the person who invented this quality assurance and testing method. Code inspections are a highly efficient test method which cannot be substituted by any other test methods. It is time consuming but according to statistics it will find up to 90% of the contained errors, if done properly. However it all depends on the methods and checks applied and on the diligence of the inspectors. It must not be confused with the so called "code review" or "walk through" which is usually done in a single meeting lasting for a couple of hours. A proper code inspection may take several days and needs the help of tools to browse the symbols in order to find the places where they are used. The code review can be used in addition to e.g. to generated acceptance of a software package by the integrators, but it must not be a substitute for a proper inspection. Proper inspections can be applied for almost all work products in the software life cycle. At the first glance they may look very time consuming. But statistical evaluations have shown that over the whole life cycle of the software development they even save resources T.Rajani Devi/ International Journal of Engineering Research and Applications (IJERA) ISSN: 2248-9622 www.ijera.com Vol. 2, Issue 1,Jan-Feb 2012, pp.552-557 553 | P a g e and thus money and improve the quality of the